一探究竟 | eBay流量管理之看不见的手
更多干货请关注“eBay技术荟”公众号
导读
本文主要介绍eBay FE Team的智能DNS服务器Global Traffic Manager（GTM）在多数据中心部署、灾备应急、关闭或添加数据中心，应用迁移等方面的杰出作用及表现。希望能给同业人员一定参考和启发。
eBay有多个数据中心（Data Center，以下简称DC），并且应用在每个数据中心都有相应的接入点（Virtual IP，以下简称VIP）。
那么问题来了，如果一个应用在多个数据中心部署，客户端的流量应该流入其中哪一个呢？
这就不得不提到从DNS入手的流量调度了。
作为域名服务系统，DNS负责把完全限定域名（Full Qualified Domain Name，以下简称FQDN）或者短名解析成IP地址。我们首先来看一个DNS查询例子：▲ 图1（点击可查看大图）
在实际情况中，从<1ms变成10+ms，跨数据中心比本数据中心的响应时间延长了数十倍以上。所以，本着尽快响应的原则，DNS服务器应该返回给客户端所在数据中心的服务IP。
我们再来看DNS针对该应用IP的配置情况。通常来说，如果一个FQDN有多个IP，那么我们就会在DNS服务器上给FQDN也配置多个IP。假设有三个数据中心，那么客户端解析出来的结果类似以下输出：
# host xxx.vip.ebay.comxxx.vip.ebay.com has address 10.1.1.1xxx.vip.ebay.com has address 10.2.2.2xxx.vip.ebay.com has address 10.3.3.3这三个IP代表着三个数据中心的同一应用接入点。无论从哪个IP，客户端拿到的响应都是一样的，唯一不同的是这些IP的地理位置。如果客户端拿到3个IP，它可以选择使用其中某个IP，但这三个IP中只有一个是本数据中心的服务IP。由于客户端是根据一定逻辑算法，在DNS返回大于一个IP时，选择其中一个，所以，它无法分辨哪一个IP是来自于本地数据中心的。
把这个问题抛给客户端，还是比较为难它了。毕竟一台客户端并不知道整个基础架构，它单方面的努力，不一定符合整体设计。所以我们把这个问题——怎么设置DNS服务器只返回本数据中心服务IP，抛给基础设施。
解 决 方 案
1
简单介绍
这里需要引入eBay使用的智能DNS服务器Global Traffic Manager（以下简称GTM）。那么，GTM是怎么接受DNS查询的呢？我们在原本的DNS服务器上配置指定的DNS zone代理是GTM（如 zone: g.ebay.com）。我们通过查询SOA和NS记录查看如下：
由此我们可以看出，DNS名字符合<xxx>.g.ebay.com的DNS记录的Nameserver 是g8.ebay.com, 即我们的主角GTM。虽然我们可以配置任意的Zone到GTM，但由于我们DNS记录有数十万条之多，并且有很多DNS记录不放在GTM反而更方便，所以我们不会把所有的DNS记录都放在GTM上。
2
一探究竟
在知道DNS zone g.ebay.com 的NS是GTM之后，我们可以在GTM上配置一个可以进行DNS解析的对象——a.g.ebay.com。它的背后有一个对象池，拿上边的三个IP来举例，池中有配置三个成员，分别是：virtual-server-10.1.1.1 virtual-server-10.2.2.2
virtual-server-10.3.3.3
我们再来看下客户端解析DNS a.g.ebay.com的过程：
1.客户端解析a.g.ebay.com。
2.请求发给客户端DNS server。
3.DNS server 发现查询的是zone：g.ebay.com，就发送查询给GTM。
4.GTM收到请求根据配置，了解到该DNS server 的所属数据中心，于是根据设置的负载均衡方法在候选IP中寻找符合条件的IP，也就是Topology。然后，GTM寻找该对象池中与请求过来的DNS server具有同一个数据中心属性的IP。再看这个IP上绑定的Monitor返回的监控状态是否健康，如果健康，就会把该IP返回给客户端。假设virtual-server-10.1.1.1符合条件，GTM就会把virtual-server-10.1.1.1所配置的IP返回给查询服务器。
5.如果IP上绑定的Monitor去发送探针而IP没有响应，那么就把它标成不可用。此时，GTM配置的Topology方法就会失败，GTM就会启用 Alternate-Mode 方法，即备用负载均衡方法。假设是Round-Robin， 那么GTM就会从另外两个可用的成员之间使用Round-Robin的方式返回给客户端一个IP。实 例
以下这些实例充分展现了GTM作为eBay智能DNS的不可替代的作用。
1
多数据中心部署
首先，我们来看一个多数据中心的应用设计。每个DC有一个VIP, 分别是VIP1，VIP2和VIP3，如下图所示：a.ebay.com 是一个DNS CNAME 记录，指向a.g.ebay.com。2
灾备应急
如果一个数据中心的VIP出现故障，那么该数据中心的VIP地址就不应该返回给Client，从而避免Client拿到错误响应，或者拿不到响应。我们来看GTM怎么处理这种情况：3
关闭数据中心
如果我们给一个数据中心的网络设备做变更，影响范围又比较大，很多应用都可能受到波及，那么我们该怎么通过GTM来避免这种影响呢？
如上图所示，假设我们要对DC1做大规模网络变更，那么我们就需要把所有在DC1的应用的VIP都主动标记成不可用，有两种办法可以实现这一操作：
A. 找到每一个应用的x.g.ebay.com（在GTM上有几千个这样的对象），然后主动把其中属于DC1的VIP标记成不可用。
B. 直接把DC1在GTM上标记成不可用（在GTM上对应DC1的只有一个对象），那么所有继承该属性的对象就会自动被GTM标记成不可用。
对比这两种方法，显然B能更方便快捷地把流量导入我们期望它进入的DC。
4
添加数据中心
如果一个应用目前只有两个DC，当我们给他添加第三个DC的时候，GTM能给我们带来什么便利呢？假设DC3是我们要给该应用添加的新DC，那么我们怎么通过GTM把它无缝的添加上去呢？如上图所示，具体步骤如下：
首先，配置VIP3-DC3到GTM，配置到a.g.ebay.com下，但是让他处于Disabled 状态，这样就不会被GTM返回给客户端。
接下来，我们修改GTM对象a.g.ebay.com的负载均衡方法成Ratio，然后把DC1和DC2的VIP Ratio 设置成99，DC3 的VIP Ratio 设置成1，再Enable DC3的VIP，此时新的VIP会拿到总流量的1%，严格来讲，应该是1/199。
最后，如果新DC的VIP被客户端访问没问题，再一点一点调节他们的Ratio值，直到达到我们期望它要分担的流量比例。
5
应用迁移
介绍了之前的几个实例，我们再来看一个稍微复杂点的例子。
如图10所示，我们有两个应用A和B，功能一样，一新一旧，但各自有自己的DNS name，即a.ebay.com和b.ebay.com，分别 CNAME 到a.g.ebay.com 和 b.g.ebay.com，每个应用都有2个VIP。现在的需求是将老应用迁到新应用上。如图11所示，我们可以通过把a.ebay.com 的CNAME记录改到新的GTM：b.g.ebay.com。
这样，当所有的客户端再去请求a.ebay.com的时候，就会到B的GTM去拿IP地址，那么所有的流量就都去了B应用。
但是，大家有没有注意到，这样做有一个巨大的风险点：所有流量在切换DNS的时候100%都到B应用了，如果有问题，那就是100%有问题，就会导致A的业务中断，生产环境可承受不起这样的变更。那我们该怎么利用GTM的便利来达到这样的目的呢？
如图12所示，首先把应用B的所有IP加入到A的GTM，同时调整负载均衡方法为Ratio，同时设置A的IP Ratio为99，B的IP Ratio为1；如果客户端解析a.ebay.com拿到的是应用B的IP，并且访问没有问题，那么持续调整两边比例，直到B的IP占据大部分比例，最后再切换DNS a.ebay.com 到b.g.ebay.com，从而实现了流量的平滑迁移的过程。
6
小结
我们可以看到，GTM 是通过事先定义客户端所使用的DNS server 所属的数据中心来感知客户端是哪个数据中心的，而在定义可用成员的时候，也必须带上数据中心的属性。这样，GTM自己就可以把两边的属性拿来做对比，根据配置的负载均衡方法和探针返回的结果，挑选出符合条件的IP返回给客户端。除此之外，它还具有丰富的配置可选项，能够满足我们对流量的调度的灵活应用。
总而言之，GTM作为eBay的智能DNS服务器，承担着eBay多数据中心之间的DNS负载均衡，给eBay的流量负载均衡做出很大贡献，配合eBay的流量负载均衡设备，管理着eBay整体的流量，也给个性化调整流量流向提供了有力的工具。
您可能还感兴趣：
分享 | eBay流量管理之Kubernetes网络硬核排查案例分享 | eBay流量管理之负载均衡及应用交付
案例分析 | 由Decimal操作计算引发的Spark数据丢失问题
超越“双十一”—— ebay百万TPS支付账务系统的设计与实现干货 | 起底eBay Flink的上云之路实战 | 总有刁民想害朕——Payments打造360°监控体系的实践
👇点击阅读原文，一键投递
eBay大量优质职位，等的就是你